Contained herein is material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction of the patent disclosure by any person as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all rights to the copyright whatsoever.
1. Field of the Invention
The invention relates generally to driving heterogeneous devices from an output server. More particularly, the invention relates to a flexible mechanism which allows jobs containing formatted data, such as image data, to be submitted to arbitrary devices.
2. Description of the Related Art
Print servers, such as the IBM(copyright) InfoPrint(copyright) Manager, traditionally provide for central management of a printing environment. A simplified printing scenario in a local area network (LAN) environment will briefly be described with reference to FIG. 1. In this example, a personal computer workstation 100 is coupled to a print server 120 via a LAN 110. The print server 120 includes a spooler 130 for controlling the spooling of data files and presentation services 140 for generating appropriate commands to drive an attached printer. The print server 120 may also include other components that are not shown for performing basic tasks, such as monitoring and configuring attached printers, and providing print job management. At any rate, when the PC workstation 100 has data to print, it sends print data to the print server 120. Among the functions typically provided by a print server is the conversion of the data stream containing the print data to a data stream supported by the printer to which the print data is destined. In this example, the print server 120 is coupled to a first printer 150 and a second printer 160. The two printers 150 and 160 may each respond to different data streams. For instance, the first printer 150 may accept the Intelligent Printer Data Stream (IPDS) and the second printer 160 may accept PostScript. Therefore, the print server 120 must provide a means for converting between the various input data streams that may be received and the two data streams accepted by the printers 150 and 160. While in this simplified example only two types of printers have been shown, it should be appreciated that real world printing environments may include many different types of printers.
Increasingly, this is the case in professional printing environments, such as commercial and production printing environments which are becoming more and more diverse. While print servers typically support diverse printing environments, such support is costly in terms of the development effort required to modify the print server software in existing inflexible architectures. For example, in order to accommodate a new data stream, it is common to add a new complex printer driver to the print server. In existing print server architectures, these print drivers must typically be developed from scratch to incorporate the rich set of features that users have come to expect. This rewriting of code is required because typically the print server""s capabilities and transforms are coded for a particular type of data stream and for a particular path through the print server. Also impacting the development efforts, is the inherent difficulty in manipulating the complex data streams that are received by print servers and transforming them into equally complex data streams required by printers. In view of the foregoing, it is desirable to provide a flexible and extensible architecture that allows support for new output devices to be added easily and inexpensively.
Another problem associated with existing print servers is the limited range of output devices supported. It is often desirable to present or deliver information in a form other than printer hard copy. Therefore, it would be advantageous to provide a mechanism to support output to destinations including fax and email, for example.
Prior art output servers also have other significant limitations which perplex end users. Fax servers report the fact that they have successfully transmitted a fax job. However, there is no indication of the success or failure of the job being received and/or handled at the destination. Often, unwary end users are surprised to discover that their xe2x80x9csuccessfulxe2x80x9d job was not successful at the receiving end. Similar limitations exist in printer control protocols that only report the success or failure of a print job being converted to image. Therefore, it is desirable to provide a mechanism by which additional job and device status may be provided to the end user.
A flexible and extensible virtual printer architecture is described. According to one aspect of the present invention final status associated with a presentation job is made available to an output server. One or more host processing threads or processes are spawned for each new presentation job received by the output server. Then, the presentation job is submitted to a presentation device for which the presentation job is destined by way of an instance of a wrapper process that is capable of communicating bi-directionally with the presentation device. After submitting the presentation job, a host job status thread or process waits for status pertaining to the presentation job. Ultimately, a final status associated with the presentation job is received by the wrapper process and the wrapper process reports the final status to the host job status thread or process. Advantageously, in this manner, a mechanism is supplied by which additional job and device status may be provided to the end user.
According to another aspect of the present invention, a method of recovering from presentation job errors is provided. A data stream generator establishes a bi-directional communication link between itself and an intermediate process. The data stream generator transmits a data stream comprising a presentation job to the intermediate process by way of the bi-directional communication link. Status information is received by the data stream generator, including an indication of a device error if the presentation device was unable to complete the presentation job. Subsequently, the presentation job may be restarted at the point of failure by the data stream generator.
According to yet another aspect of the present invention, job and device status may be reported asynchronously. One or more host processing threads or processes are spawned for each new presentation job received. A first presentation job is submitted to a presentation device for which the presentation job is destined by way of a first instance of a wrapper process that communicates bi-directionally with the presentation device. Subsequently, a second presentation job is submitted to the presentation device by way of a second instance of the wrapper process. A first and second job status thread or process wait for status pertaining to the first and second presentation jobs, respectively. A final status associated with the second presentation job is received by the second instance of the wrapper before a final status associated with the first presentation job is received by the first instance of the wrapper. Then, the second instance of the wrapper process reports the final status to the second job status thread or process.
Other features of the present invention will be apparent from the accompanying drawings and from the detailed description which follows.